<html>
<head><meta charset="utf-8"><title>mem-markers v0.1 · project-safe-transmute · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/index.html">project-safe-transmute</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html">mem-markers v0.1</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="197589683"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/197589683" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#197589683">(May 14 2020 at 17:27)</a>:</h4>
<p>Hey all. I'm thinking about making a public announcement to mem-markers so we can get people discussing it. Please let me know if you think that releasing will lead to quality discussion. <a href="https://github.com/rust-secure-code/mem-markers">https://github.com/rust-secure-code/mem-markers</a><br>
Of particular interest is how we handle this: <a href="https://github.com/rust-secure-code/mem-markers/issues/6">https://github.com/rust-secure-code/mem-markers/issues/6</a> It seems like this is in a way a meta trait. For  instance, for zeroable, we need to decide if the trait means, this type is fine to be viewed at any point as zeros OR one particular state is has is zeros but it has invariants it keeps track off so don't just <code>std::mem::zeroed</code> initialize it.</p>



<a name="197619394"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/197619394" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#197619394">(May 14 2020 at 21:17)</a>:</h4>
<p>In general, more eyes is probably a good idea. for the zeroed thing i'll keep the discussion of it inside that thread so it doesn't get spread out.</p>



<a name="198131760"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198131760" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198131760">(May 19 2020 at 21:52)</a>:</h4>
<p>That issue was confusing to me, as it's not clear if it means "This trait indicates a type has no internal validity requirements" or if it means it's repr(transparent) around a wrapped type and imposes no additional constraints upon the wrapped type. Different comments seem to be discussing different things</p>



<a name="198637532"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198637532" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Casey Rodarmor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198637532">(May 25 2020 at 06:28)</a>:</h4>
<p>I would definitely like to use this!</p>
<p>I am writing a serialization library that casts to and from bytes, and was just about to write versions of <code>NoUninit</code>, <code>FromBytes</code>, and <code>ToBytes</code> myself.</p>
<p>I notice that <code>FromBytes</code> isn't implemented for f64 and f32, but I think perhaps it can be, since <code>f32/64::from_bits</code> is using a transmute from <code>u32/64</code> under the hood.</p>
<p>One thing that I would like to see would be a trait that asserts that a type has alignment == 1. In my case, my format does not include padding, so conversion from byte strings with any alignment must be safe.</p>
<p>Would you be interested in an <code>Unaligned</code> trait via PR?</p>
<p>Are you planning on publishing the crate to <a href="http://crates.io">crates.io</a>?</p>
<p>I think you might find the <code>zerocopy</code> crate interesting, which has some similar traits: <a href="https://docs.rs/zerocopy/0.3.0/zerocopy/">https://docs.rs/zerocopy/0.3.0/zerocopy/</a></p>
<p>Edit: Oop, I notice that you already mention alignment traits and <code>zerocopy</code> in an issue, I'll add a comment there.</p>



<a name="198637821"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198637821" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198637821">(May 25 2020 at 06:35)</a>:</h4>
<p>I think that traits for align==X is certainly possible.</p>



<a name="198637966"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198637966" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198637966">(May 25 2020 at 06:38)</a>:</h4>
<p>note that <em>owned</em> casts (such as <code>[u8;4]</code> to <code>u32</code>) can always be done safely even if the target type is a higher alignment because when the value is moved across the casting function call and back it implicitly moves to a location with the necessary alignment.</p>



<a name="198674053"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198674053" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198674053">(May 25 2020 at 14:24)</a>:</h4>
<blockquote>
<p>Would you be interested in an Unaligned trait via PR?</p>
</blockquote>
<p>Absolutely! I'm not so sure if I love the name as it's not necessarily _un_aligned but rather always aligned.</p>



<a name="198674156"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198674156" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198674156">(May 25 2020 at 14:25)</a>:</h4>
<blockquote>
<p>Are you planning on publishing the crate to <a href="http://crates.io">crates.io</a>?</p>
</blockquote>
<p>Yep, I'll probably announce this today on Twitter and then publish 0.1 soon</p>



<a name="198674575"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198674575" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198674575">(May 25 2020 at 14:29)</a>:</h4>
<p>pinging <span class="user-mention" data-user-id="224471">@Lokathor</span> <span class="user-mention" data-user-id="132362">@Joshua Liebow-Feeser</span> <span class="user-mention" data-user-id="219211">@Jack Wrenn</span> since I'm probably going to announce mem-markers today, and there's naturally a bit of overlap with your crates. If people ask what the relationship is, my official response is that mem-markers is much lower level and more general purpose. It's meant to allow programmers to explicitly state memory invariants of their types as traits which can help with safely implementing transmute but is also useful in other situations. Thoughts?</p>



<a name="198675813"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198675813" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198675813">(May 25 2020 at 14:42)</a>:</h4>
<p>Also going to ping <span class="user-mention" data-user-id="120791">@RalfJ</span> since this is highly relevant to unsafe. <span class="user-mention" data-user-id="120791">@RalfJ</span>, please let me know what you think of the overall direction of the crate. The idea is to take these traits and eventually move most if not all into the std lib so that people can more easily express what type of memory invariants their types have. <a href="https://github.com/rust-secure-code/mem-markers">https://github.com/rust-secure-code/mem-markers</a></p>



<a name="198675856"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198675856" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198675856">(May 25 2020 at 14:42)</a>:</h4>
<p>And of course, <span class="user-mention" data-user-id="239881">@Josh Triplett</span> since he was helping me with the safe transmute pre-RFC which led to this work</p>



<a name="198677052"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198677052" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198677052">(May 25 2020 at 14:56)</a>:</h4>
<p><span class="user-mention" data-user-id="224872">@Ryan Levick</span> What do you mean by "lower level"? Zerocopy and typic also define general-purpose marker traits. At a glance, mem-markers seems pretty similar to zerocopy.</p>
<p>Typic also has the goal of being useful outside of transmutes, like communicating abi-breaking changes. In the latest stab at stability marker traits, you express lower and upper bounds for a type's alignment, validity and size.  So, this lets you do clever things like expressing that you _might_ add a field to a struct where there once was padding.</p>



<a name="198677598"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198677598" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198677598">(May 25 2020 at 15:02)</a>:</h4>
<p>Hmmm then perhaps there is more overlap then I had thought. mem-markers is meant to be _only_ markers (and derives for those markers) with essentially no functionality built in. This is to encourage its usage across many different libraries that might have wide range of uses. This seems like a much easier sell for moving into the std lib as its as flexible as you can get and ultimately pretty forward proof. My thought was that zerocopy and Typic could be built on top of mem-markers, and that the existing marker traits in those crates could be deprecated in favor of the traits in mem-markers</p>



<a name="198677663"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198677663" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198677663">(May 25 2020 at 15:03)</a>:</h4>
<p>For example, mem-markers will never expose a safe-transmute function, but one could easily be written using it.</p>



<a name="198677791"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198677791" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198677791">(May 25 2020 at 15:04)</a>:</h4>
<p><span class="user-mention" data-user-id="219211">@Jack Wrenn</span> For some libraries at work, I could easily imagine us using mem-markers (because it's so straight forward), but the use of Typic would be a harder sell since it does more</p>



<a name="198677999"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198677999" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198677999">(May 25 2020 at 15:06)</a>:</h4>
<p>Typic could never be implemented atop the mem-markers traits, unfortunately; it's basis is Frunk's <code>Generic</code> trait and another trait that encodes any <code>repr</code> modifiers.</p>



<a name="198678154"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198678154" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198678154">(May 25 2020 at 15:07)</a>:</h4>
<p>I think the position should be that <code>mem-markers</code> aims to replace most or all of the functionality/purpose of the existing casting crates.</p>



<a name="198678295"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198678295" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198678295">(May 25 2020 at 15:09)</a>:</h4>
<p>we're moving things out of <a href="http://crates.io">crates.io</a> crates and into <code>core</code> and the compiler.</p>



<a name="198678428"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198678428" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198678428">(May 25 2020 at 15:10)</a>:</h4>
<p>It seems like <span class="user-mention" data-user-id="219211">@Jack Wrenn</span> is of the opinion that typic and men-markers overlap completely. Is that true, Jack?</p>



<a name="198678667"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198678667" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198678667">(May 25 2020 at 15:12)</a>:</h4>
<p>I’m not sure though if the hope that typic moves into core, but that is directly a hope of men-markers</p>



<a name="198678737"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198678737" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198678737">(May 25 2020 at 15:13)</a>:</h4>
<p>(I can write up something for the readme comparing these crates and send it around for people to give their feedback)</p>



<a name="198678772"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198678772" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198678772">(May 25 2020 at 15:13)</a>:</h4>
<p>Typic's approach is strictly more powerful than mem-markers. There aren't any markers you can express with the mem-markers approach that can't be expressed with typic (but the reverse isn't true).</p>
<p>The mem-markers approach of picking a few marker traits and trying to gate their derives on macro-based checks is substantially similar to zerocopy.</p>



<a name="198679101"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198679101" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198679101">(May 25 2020 at 15:16)</a>:</h4>
<p>I’d agree with that. The advantage of men-markers I’d argue is simplicity (both implementation wise and conceptually).</p>



<a name="198679245"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198679245" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198679245">(May 25 2020 at 15:18)</a>:</h4>
<p>And yes, my (perhaps unrealistic) hope would be of getting a safe transmute into core, that's as easy to use as the existing transmute intrinsics but with none of the dangers. I think typic's layout stability markers are also much more expressive, but they're not checkable without its safe-transmute machinery. (For a type <code>T</code>, you provide two types <code>A</code> and <code>B</code>. You promise that <code>T</code> is always transmutable _into_ <code>A</code>, and always transmutable _from_ <code>B</code>. A change to <code>T</code> that breaks these promises is a breaking change. This is enforced by typic.)</p>



<a name="198679409"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198679409" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198679409">(May 25 2020 at 15:20)</a>:</h4>
<p><span class="user-mention" data-user-id="224872">@Ryan Levick</span> If we instead integrated a frunk-style <code>Generic</code> trait into core, plus a marker trait that's implemented for things that are <code>repr(C)</code>, both the mem-markers <em>and</em> typic approaches could be built atop it.</p>



<a name="198679717"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198679717" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198679717">(May 25 2020 at 15:24)</a>:</h4>
<p><span aria-label="thinking" class="emoji emoji-1f914" role="img" title="thinking">:thinking:</span> I’m not saying that’s a bad idea, I’m just saying I’m skeptical enough that I think having another approach would be worth exploring. I agree that the men-markers approach is related to zero-copy but it’s a slightly simplified version. I think having that as a “competitor” (in the friendliest sense of the word) to typic is worth it 😀. <span class="user-mention" data-user-id="219211">@Jack Wrenn</span> do you think releasing men-markers will make the Rust ecosystem worse?</p>



<a name="198679903"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198679903" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198679903">(May 25 2020 at 15:26)</a>:</h4>
<p>Oh, not at all. I just mean:  if you want to put something in core, there's a slightly different foundation that accommodates both of our approaches. I don't want to close the door on _ever_ providing a safe transmute function.</p>



<a name="198680209"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198680209" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198680209">(May 25 2020 at 15:31)</a>:</h4>
<p>Yea I'm not saying that I necessarily want mem-markers to go into core _as it is right now_. I have some reservations about providing type level programming primitives in core, but I don't think those reservations are relevant here. <br>
So Typic covers the same purposes as mem-markers and more  (e.g., providing a safe transmute function). Typic aims to get there by using type level programming while mem-markers aims for a less powerful solution using simple marker traits and derive macros. While we may each have our favorites in this race, we're both willing to say that the other should exist to make sure we ultimately end up with the right solution.</p>



<a name="198680525"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198680525" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198680525">(May 25 2020 at 15:34)</a>:</h4>
<p>I'll add this to the readme. <span class="user-mention" data-user-id="224471">@Lokathor</span> thoughts on how mem-markers relates to bytemuck?</p>



<a name="198680563"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198680563" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198680563">(May 25 2020 at 15:35)</a>:</h4>
<p>And <span class="user-mention" data-user-id="132362">@Joshua Liebow-Feeser</span> I assume your opinion is that you hope zerocopy will eventually be built on top of typic (or deprecated in favor of it)?</p>



<a name="198681261"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198681261" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198681261">(May 25 2020 at 15:42)</a>:</h4>
<p><span class="user-mention" data-user-id="219211">@Jack Wrenn</span> how would one express in typic that a type is zeroable?</p>



<a name="198681841"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198681841" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198681841">(May 25 2020 at 15:48)</a>:</h4>
<p>Something like this:</p>
<div class="codehilite"><pre><span></span><code><span class="cp">#[repr(u8)]</span><span class="w"> </span><span class="k">enum</span> <span class="nc">Zero</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="n">Z</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="mi">0</span><span class="k">u8</span><span class="p">;</span><span class="w"> </span><span class="p">}</span><span class="w"></span>

<span class="k">pub</span><span class="w"> </span><span class="k">trait</span><span class="w"> </span><span class="n">Zeroable</span><span class="o">&lt;</span><span class="n">Options</span><span class="o">&gt;</span><span class="w"> </span><span class="p">{}</span><span class="w"></span>

<span class="k">impl</span><span class="o">&lt;</span><span class="n">T</span><span class="p">,</span><span class="w"> </span><span class="n">Options</span><span class="o">&gt;</span><span class="w"> </span><span class="n">Zeroable</span><span class="o">&lt;</span><span class="n">Options</span><span class="o">&gt;</span><span class="w"> </span><span class="k">for</span><span class="w"> </span><span class="n">T</span><span class="w"></span>
<span class="k">where</span><span class="w"> </span><span class="n">T</span>: <span class="nc">TransmuteFrom</span><span class="o">&lt;</span><span class="n">Array</span><span class="o">&lt;</span><span class="n">Zero</span><span class="p">,</span><span class="w"> </span><span class="n">SizeOf</span><span class="o">&lt;</span><span class="n">T</span><span class="o">&gt;&gt;</span><span class="p">,</span><span class="w"> </span><span class="n">Options</span><span class="o">&gt;</span><span class="w"></span>
<span class="p">{}</span><span class="w"></span>
</code></pre></div>



<a name="198681923"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198681923" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198681923">(May 25 2020 at 15:49)</a>:</h4>
<p>Is the plan to expose that trait in typic or leave that to another crate?</p>



<a name="198682195"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198682195" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198682195">(May 25 2020 at 15:52)</a>:</h4>
<p>Because if the plan is _not to_ then really typic could be seen as lower-level than mem-markers, and one could imagine implementing <code>mem-markers</code> in terms of <code>typic</code>. But even still, having a <code>Zeroable</code> trait that everyone can use no matter its implementation is useful</p>



<a name="198682566"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198682566" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198682566">(May 25 2020 at 15:57)</a>:</h4>
<p>Comparison of crates in README: <a href="https://github.com/rust-secure-code/mem-markers/pull/19">https://github.com/rust-secure-code/mem-markers/pull/19</a></p>



<a name="198682697"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198682697" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198682697">(May 25 2020 at 15:59)</a>:</h4>
<p>Yeah, I agree! Typic's approach is super expressive.</p>
<p>As its developer but <em>not</em> end-user, I've waffled on how much of typic's guts to expose. I'd like Typic to demonstrate that it provides a _really_ powerful foundation for other abstractions like <code>Zeroable</code>, but I also want to minimize the allergic reactions that would surely occur if it even appeared like I was proposing exposing typenum in the core library.</p>
<p>So, <code>TransmuteFrom</code> and <code>TransmuteInto</code> don't expose any gnarly type-level programming stuff, but surfacing <code>SizeOf</code> does.</p>
<p>Having talked to Josh a bit about the future of typic, it makes sense from an end-user perspective to provide some nice shorthands like <code>FromBytes</code>, <code>FromZeros</code> and <code>AsBytes</code>.</p>



<a name="198683039"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198683039" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198683039">(May 25 2020 at 16:04)</a>:</h4>
<blockquote>
<p>Having talked to Josh a bit about the future of typic, it makes sense from an end-user perspective to provide some nice shorthands like FromBytes, FromZeros and AsBytes.</p>
</blockquote>
<p>Its obviously still super early, but one thing that would make Typic more digestable for use in projects at my work would be for there to be a minimal typic which only exposes TransmuteFrom/TransmuteInto and related low-level machinary for expressing invariants. Then have something like mem-makers which exposes a bunch of short hand traits implememented in terms of the low level machinary. And _then_ a high level zerocopy style crate which packages all this up and exposes a nice (and maybe slightly opinionated) set of APIs.</p>
<p>Most would use the high level APIs, those doing something a bit trickier might use the mid level (mem-markers) style crate, and only in really desparate times would you need to reach for the lowest level crate</p>



<a name="198683294"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198683294" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198683294">(May 25 2020 at 16:06)</a>:</h4>
<p>The thing is that the mid-level mem-markers crate being implemented in terms of the low level machinary is really just an implementation detail. I could imagine releasing mem-markers as it is today, and in a non-breaking way, moving to implementation being done in terms of low level typic machinary</p>



<a name="198683303"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198683303" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198683303">(May 25 2020 at 16:06)</a>:</h4>
<p>My hope is that mem-markers and other work with core library functions can completely move <code>bytemuck</code> into <code>core</code></p>



<a name="198683477"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198683477" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198683477">(May 25 2020 at 16:08)</a>:</h4>
<p>I'd probably write a 2.0 version that is re-done on top of core and keeps the few things that probably won't end up in core as soon, like the <code>offset_of!</code> macro</p>



<a name="198683623"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198683623" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198683623">(May 25 2020 at 16:10)</a>:</h4>
<p>The phrases "high level" and "low level" seem a bit wonky to me.</p>
<p>In one respect, typic's <code>TransmuteFrom</code>is "low level" because things like <code>FromBytes</code> can be implemented on top of it (but not the other way around). </p>
<p>But, in another respect, using <code>TransmuteFrom</code>is as simple as calling <code>.transmute()</code>. There's no worrying about implementing marker traits, or proving correctness yourself. <code>TransmuteFrom</code> <em>feels</em> like a very high-level API.</p>
<p>Typic's notion of "low level" basically includes all the things it doesn't expose (for the most part): size, alignment and validity calculations on individual types.</p>



<a name="198684089"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198684089" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198684089">(May 25 2020 at 16:16)</a>:</h4>
<p>I think that's a fair criticism of the terms low-level and high-level. The fact remains that exposing "high-level" marker traits is useful. For example, the zeroable trait we discussed above. But I suppose you would hope to see those directly in typic at some point</p>



<a name="198684213"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198684213" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198684213">(May 25 2020 at 16:18)</a>:</h4>
<p>Yeah, they kinda sorta already exist as a documentation example: <a href="https://docs.rs/typic/0.2.3/typic/layout/index.html">https://docs.rs/typic/0.2.3/typic/layout/index.html</a></p>



<a name="198684335"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198684335" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198684335">(May 25 2020 at 16:19)</a>:</h4>
<p>Yea but the utility isn't from being easy to create them yourself. It's from having a ecosystem-wide agreed upon set of traits for expressing these concepts. There's much less utility when each crate has to define their own AsBytes,Zeroable, etc.</p>



<a name="198684548"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198684548" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198684548">(May 25 2020 at 16:22)</a>:</h4>
<p>I guess what I'm coming to realize is that mem-markers are useful no matter if they're implemented like they are today or implemented in terms of typic. They exist as a separate crate as to not tie themselves unnecessarily to a particular implementation. Perhaps, they will one day be built on typic primitives, but that should be transparent to the user.</p>



<a name="198684726"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198684726" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198684726">(May 25 2020 at 16:25)</a>:</h4>
<p>Yes, however, one thing that will make that very difficult to ever do is typic takes a blanket impl approach. Turning a non-blanket impl'd trait into a blanket-impl'd trait is a breaking change.</p>



<a name="198685004"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198685004" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198685004">(May 25 2020 at 16:28)</a>:</h4>
<p>That's a good point. Though I'm having a hard time picturing what exactly would break.</p>



<a name="198685236"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198685236" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198685236">(May 25 2020 at 16:31)</a>:</h4>
<p>There's a distinction between it being safe to <code>FromBytes</code> a type, and it being stable to do so.</p>
<p>When a trait like <code>FromBytes</code> is opt-in, implementing it implies that it's both safe <em>and</em> stable to rely on that behavior.</p>



<a name="198685373"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198685373" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198685373">(May 25 2020 at 16:32)</a>:</h4>
<p>All mem-marker types are currently opt-in. Are you saying that typic won't allow for opt-in traits?</p>



<a name="198685414"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198685414" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198685414">(May 25 2020 at 16:33)</a>:</h4>
<p>Yep. An trait with a blanket implementation cannot also have opt-in implementations (well, until <code>#[marker]</code> is stabilized).</p>



<a name="198685420"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198685420" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198685420">(May 25 2020 at 16:33)</a>:</h4>
<p>How typic handles this is its traits take an extra <code>Options</code> parameter. By 'default', that parameter is <code>()</code>, which means typic should perform all checks. If you want to neglect the stability check (which is the only check that can be safely neglected), you must state so <em>utterly explicitly</em>: e.g.,  <code>T: TransmuteFrom&lt;U, NeglectStability&gt;</code></p>



<a name="198685578"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198685578" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198685578">(May 25 2020 at 16:35)</a>:</h4>
<p>So, basically, typic distinguishes between whether something can soundly be done, and whether it can stable-y be done.</p>



<a name="198685829"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198685829" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198685829">(May 25 2020 at 16:38)</a>:</h4>
<p>Yea mem-markers uses different traits for that (or at least will at some point).</p>



<a name="198686651"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/198686651" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rylev <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#198686651">(May 25 2020 at 16:51)</a>:</h4>
<p>Typic could be used to verify validity of the derive macros in mem-markers but yea you're right that the mem-markers themselves can't be implemented in terms of typic primitives.</p>



<a name="199172114"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/199172114" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#199172114">(May 29 2020 at 15:44)</a>:</h4>
<p><span class="user-mention silent" data-user-id="224872">Ryan Levick</span> <a href="#narrow/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1/near/198675813">said</a>:</p>
<blockquote>
<p>Also going to ping <span class="user-mention silent" data-user-id="120791">RalfJ</span> since this is highly relevant to unsafe. <span class="user-mention silent" data-user-id="120791">RalfJ</span>, please let me know what you think of the overall direction of the crate. The idea is to take these traits and eventually move most if not all into the std lib so that people can more easily express what type of memory invariants their types have. <a href="https://github.com/rust-secure-code/mem-markers">https://github.com/rust-secure-code/mem-markers</a></p>
</blockquote>
<p>(without having read this entire thread here)<br>
I am pretty swamped I'm afraid, so I can't do an in-depth review. the approach of pinning down interesting properties of types and reflecting them in traits makes a lot of sense to me. some of it however will rely on things like "is there padding" which is not easily available a a trait bound.</p>
<p>Regarding the concrete traits that you have:</p>
<ul>
<li>"types that do not have any unintialized bytes", what exactly does that mean? does the <a href="https://www.ralfj.de/blog/2018/08/22/two-kinds-of-invariants.html">validity invariant or the safety invariant</a> rule out uninit bytes? Right now uninit <code>i32</code> is UB but this might change in the future so this is not something anyone should rely on. OTOH, you can surely rely on uninit <code>i32</code> never being safe to pass across API boundaries. How does this differ from <code>AsBytes</code>, which sounds closely related?</li>
<li><code>ByteComplete</code> seems like a really odd name, not sure what is "complete" about this. Also do you mean any <em>initialized</em> array, or really any array? in case of the former, there are hardly any types like that. also the question about validity invariant vs safety invariant comes up again. (as it does for most of these traits actually). How does this differ from <code>FromBytes</code>?</li>
</ul>



<a name="199172292"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/199172292" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#199172292">(May 29 2020 at 15:45)</a>:</h4>
<p>As a general advice, it would help to list for each trait two examples: a type that satisfies the trait, and a type that does not -- picked as well as possible to indicate the distinction that this trait is making.</p>



<a name="199181318"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/199181318" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#199181318">(May 29 2020 at 16:53)</a>:</h4>
<p>if you can't rely on an i32 being init, both unsafe and safe are in an immense amount of trouble.</p>



<a name="199186287"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/199186287" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#199186287">(May 29 2020 at 17:36)</a>:</h4>
<p><span class="user-mention" data-user-id="224471">@Lokathor</span> to be clear, the <em>safety</em> invariant definitely says that it is init</p>



<a name="199186364"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/199186364" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#199186364">(May 29 2020 at 17:36)</a>:</h4>
<p>but whether the <em>validity</em> invariant also says that is up for debate, and I dont think answering this with "no" (i.e., allowing uninit) will necessarily cause trouble</p>



<a name="199186391"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/199186391" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#199186391">(May 29 2020 at 17:36)</a>:</h4>
<p>public APIs have to handle all <em>safe</em> instances of a type, not all <em>valid</em> ones.</p>



<a name="199187770"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/199187770" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#199187770">(May 29 2020 at 17:47)</a>:</h4>
<p>I think that the mem-markers should exclusively work in terms of safe, or at least have any "valid but unsafe" situations specifically marked and documented and such.</p>
<p>but that hasn't been specifically decided upon yet.</p>



<a name="199244205"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/mem-markers%20v0.1/near/199244205" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/mem-markers.20v0.2E1.html#199244205">(May 30 2020 at 07:43)</a>:</h4>
<p>Fair. But I think the crate should be explicit about that.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>